Quarterly Progress Report #3
What I worked on: Nov '24 - Jan '25
This quarter was easily my most diverse yet! I made progress in several areas: Bitdevs talk, ChillingDKG review & test vectors, shifted Shamir shares, Schnorr adaptor Rust bindings, and BIP FROST Signing.
In November, Bitshala hosted a Bitcoin developer summit where I gave a talk on Schnorr signatures. I started with the basics of group theory, then built up intuition for the signature structure and its applications. Finding ways to introduce Schnorr signatures to developers new to cryptography was an interesting challenge—keeping the math approachable without oversimplifying the important details. The slides are available here. This talk lays the groundwork for future sessions, where I plan to introduce adaptor signatures, MuSig2, and FROST in upcoming BitDevs meetups.
I’ve shared my ChillDKG review comments with the authors. The two major issues that I found during my reviews were:
Potential nonce reuse attack in
schorr_sign- linkImproper handling of scalar values during deserialization - link
The authors resolved both issues promptly. I also volunteered to implement test vectors for the ChillDKG spec, discussed the design with the authors, and settled on an approach: https://github.com/BlockstreamResearch/bip-frost-dkg/issues/35. I’m currently working on a proof of concept in my fork.
While reviewing ChillDKG, I noticed an interesting property of Shamir shares that doesn’t appear in the additive shares used by MuSig2. In a t-of-n Shamir sharing scheme, where combining shares yields a shared secret c, shifting each share by a constant k:
results in a shared secret of c + k. To verify this, I quickly sketched out a mathematical proof.
The implication is that this property could slightly simplify the partial signature aggregation algorithm in BIP FROST Signing, as it eliminates the need to track tweaks. I’m not yet sure how useful this simplification would be, but I plan to analyze the use case next quarter. Interestingly, another researcher independently suggested a similar idea for simplifying partial signature aggregation.
BIP FROST Signing and ChillDKG have diverged in some design decisions and terminologies, with the most notable difference being how they handle participant identifiers. I’ve been working on a pull request to align the Signing BIP with ChillDKG’s approach to participant identifiers.
https://github.com/siv2r/bip-frost-signing/pull/17
I also created Rust bindings for my Schnorr adaptor module pull request to the libsecp256k1-zkp repository. Once that pull request is merged, I plan to open the bindings pull request in the rust-secp256k1-zkp repository.
Reflections
I had to pick up Rust to create the adaptor signature bindings. This was actually my second attempt at learning the language—the first was while writing my Spiral grant proposal. Surprisingly, this time around, Rust felt much more intuitive. I was able to form a clearer mental model of ownership and borrowing rules, which made working with the language smoother. Fortunately, the rust-secp256k1-zkp bindings didn’t require more advanced concepts like lifetimes, which I’m still a bit fuzzy on.
The main reason I worked on adaptor signature bindings this quarter was that a master’s student researching oracle-based conditional payments for their thesis reached out, expressing interest in using the Schnorr adaptor signature module in libsecp256k1-zkp. I’m glad to see external interest in the module and am looking forward to their feedback once they start integrating it.
Beyond just getting the bindings done, this work gave me a solid understanding of the rust-secp256k1 and rust-secp256k1-zkp codebases. I now feel confident that I could implement bindings for other modules—like FROST and ChillDKG—much more quickly in the future.
Next Steps
My immediate next step is to create test vectors for the ChillDKG. After that, I plan to focus on BIP FROST Signing—addressing theStack’s review comments, aligning it with ChillDKG, and completing the remaining TODOs.